Why

Optional test variants (test openj9, test windows, test native) were gated by GitHub PR labels via pull_request: [labeled]. We tried three progressively more elaborate ways to make the labeled trigger work, and all of them broke:

1. Separate rebuild-pull-request-on-label.yml that re-invoked the build via workflow_call on test * label adds. Two workflows, two concurrency groups, full build ran twice in parallel every time the labeler auto-applied test native (Remove deprecated redact-query-parameters and db-sqlcommenter configurations #18229).
2. Shared fixed concurrency group so the labeled run cancelled the initial run (Deduplicate PR build runs when a test label is auto-added #18235). The cancelled run's check_suite then sat on the PR as "canceled / failed" check_runs, shadowing the real build in the PR Checks UI (Unify PR build into a single workflow with a dispatcher #18295).
3. Unified into one workflow with pull_request: [labeled] plus a job-level if: filtering to test * labels (Unify PR build into a single workflow with a dispatcher #18295). But concurrency: is evaluated before the job-level if: filter, so adding any label (renovate, dependabot, code-review-sweep, the labeler, a human) entered the per-PR group and cancelled the in-progress real build (Code review sweep (run 25154254051) #18441). Concrete failure: PR Code review sweep (run 25154254051) #18441, run 25156724872 — every job ended within ~2 seconds with no steps executed. And even after a conditional concurrency group keyed off the label, the labeled run's check_suite still displaced the real build's check_suite in the PR Checks UI (GitHub keys that view by workflow file, latest check_suite wins).

All three failures share a root cause: pull_request: [labeled] was never meant to be a build-configuration trigger.

What

Drop labeled from the trigger entirely. Read labels from github.event.pull_request.labels (present on every pull_request event) and gate optional jobs with contains(...). Skipped required jobs satisfy branch protection so auto-merge still gates correctly. test native detection (formerly the labeler's glob) moves inline as a resolve-native job in the build.

Trade-off

Adding a test openj9 / test windows label doesn't retrigger the build. Push another commit or close/reopen the PR to pick it up. A new comment-on-test-label.yml workflow posts a reminder comment when one of those labels is added so this isn't surprising. (Safe under pull_request_target because that workflow doesn't check out or run any PR code — only gh pr comment.)